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ABSTRACT 

The Near Earth Asteroid Rendezvous 
(NEAR) program at The Johns Hopkins 
University Applied Physics Laboratory is 
scheduled to launch the first spacecraft in 
NASA’s Discovery program. The Discovery 
program is to promote low cost spacecraft 
design, development, and mission operations 
for planetary space missions. In this paper, 
the authors describe the NEAR mission and 
discuss the design and development of the 
NEAR Mission Operations System and the 
NEAR Ground System with an emphasis on 
those aspects of the design that are con- 
ducive to low-cost operations. 

INTRODUCTION 

NEAR will launch in February 1996 and 
rendezvous with the asteroid Eros in January 
1999. The spacecraft is to orbit Eros for up 
to a year, mapping the asteroid and collect- 
ing data on its gravitational and magnetic 
fields as well as its elemental composition. 
Significant challenges are anticipated in 
NEAR mission operations. NEAR will be 
the first spacecraft to conduct orbital opera- 
tions around a small, irregularly shaped 
planetary body. Stringent orbital plane 
restrictions are required to simultaneously 
maintain instrument fields of view of the 
asteroid, communications antenna coverage 
of the Earth, and illumination on the solar 
panels. During certain portions of the year 
of asteroid operations, orbital maneuvers 
may be required every three days to 
maintain the orbital plane. Given the 
irregular shape and size of the asteroid, 
simple nadir pointing mapping strategies 
will not be sufficient for conducting opera- 
tions at Eros; a flexible planning strategy 
must be implemented to coordinate scientific 
priorities given limited observation 
opportunities. These scientific observations 
must be combined with routine subsystem 
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maintenance, orbital maintenance, and 
navigation requirements. A sophisticated 
sequence planning system with quick 
reaction capability is required (priorities and 
orbital dynamics can be expected to change 
on a continuous basis, requiring constant 
adaptation of operations to mission science 
needs). 

These considerations generally increase 
the cost of mission operations in an era 
when Mission Operations and Data Analysis 
(MO & DA) costs are being scrutinized as 
never before. If NEAR and future Discov- 
ery class missions are to succeed, they must 
set new standards for cost efficiency. The 
goal of this paper is to show how mission 
operations costs can be controlled by the 
application of advanced technologies and 
operations concepts. 

Organization of Paper 

Following the Abstract and Introduction, 
this paper begins with a discussion of low 
cost mission operations. This is followed by 
a description of the NEAR Mission 
Operations System (MOS) which highlights 
those elements of the system design that 
contribute to low cost mission operations. 
Following the MOS description is a section 
detailing the design of the NEAR Ground 
System (NGS), again, with an emphasis on 
the low cost operations aspects of the 
design. Finally, we provide a summary of 
our recommendations for implementing low 
cost mission operations on Discovery class 
missions. 

LOW COST MISSION OPERATIONS 

The MOS is often the last element of the 
program to be developed; as such, the MOS 
frequently must make up for gaps and 
problems that have developed in the mis- 
sion, spacecraft, and instrument designs. 
The MOS is generally custom developed for 
each mission, which is decidedly non- 
optimal from a cost-effectiveness viewpoint. 


Mission Operations costs can be divided 
into two major categories: development 
costs (mostly pre-launch) and operations 
costs (mostly post-launch). In the following 
discussion, potential cost saving measures 
are introduced in each category. 

System Development 

System development costs are primarily 
pre-launch and are generally incurred late in 
the pre-launch program. If a program gets 
into budget problems late in the spacecraft 
development phase (this is not uncommon), 
mission operations development costs fre- 
quently attract the attention of the budgetary 
ax-wielder. Saving money in development 
costs at the expense of repetitive costs in the 
post-launch mission operations phase is not 
cost efficient over the mission life cycle , yet 
this trade is frequently made. In the follow- 
ing, several approaches to saving costs in 
MOS development are discussed which do 
not compromise either mission capability or 
total life cycle cost. 

Existing Infrastructure 

Always take advantage of existing 
infrastructure where cost efficient. If an 
existing voice communications system or 
ground station network will work for your 
mission, why re-invent the wheel? It should 
be noted that existing infrastructure is not 
always cost efficient . Maintenance or 
personnel costs associated with outdated 
systems can negate their advantage. Each 
element must be individually evaluated on 
the basis of cost-efficiency. 

Commercial-Off-The-Shelf Systems 

Examine Commercial Off-The-Shelf 
(COTS) hardware and software systems for 
applicability to your program , again, on a 
cost efficiency basis. COTS systems have 
shown a tremendous growth in capability in 
recent years; low-cost programs can get a lot 
of bang for the buck compared to the devel- 
opment costs of custom systems. There are 
two major shortcomings of COTS systems. 
First, "COTS" elements for space mission 
applications are not the shrink-wrapped 
products we have come to expect in the truly 
commercial (i.e., PC) marketplace; they lack 
the smooth polish of a mass market product 
(e.g., documentation, on-line technical sup- 


port) and must frequently be customized for 
each application. Make certain that the costs 
of these modifications are considered in the 
total cost of a COTS system. Second, many 
functions that are necessary to operate a 
complex space mission are not found in the 
COTS offerings. Straight-forward Teleme- 
try, Tracking, and Control (TT&C) opera- 
tions for a commercial satellite (such as a 
communications satellite) are significantly 
different from operations for a planetary 
exploration mission with complex planning 
tasks and command sequence development. 
COTS products tend to be stronger in meet- 
ing the needs of commercial users than sci- 
entific mission planners. 

Concurrent Engineering 

Use modern concurrent engineering de- 
velopment techniques. Traditional ap- 
proaches to system development (re- 
quirement definition, specification devel- 
opment, preliminary and detailed design, 
fabrication, and test) are slow, cumbersome, 
and costly. Modern methods of system 
development such as concurrent engineering 
and rapid prototyping can be faster and 
cheaper. There are risks in this approach, 
however, the benefits generally outweigh 
these risks. For Discovery programs, higher 
risks must be tolerated to achieve the 
avowed goals of faster, better, and cheaper. 

Design for Operability 

Design the spacecraft and Mission 
Operations System for operability. Too 
often, flexibility and operability are rele- 
gated to the ground system and mission 
operations team to save development costs 
in the spacecraft. While this is an under- 
standable approach (complexity vs. reliabil- 
ity tradeoffs in the spacecraft favor simplic- 
ity), this may not be the optimal approach. 
In some cases, relatively minor changes in 
spacecraft or instrument design can signifi- 
cantly save in operations costs (sometimes, 
over and over again). For example, thermal 
and power robustness may eliminate the 
need for complex analysis of every 
maneuver sequence, saving time and money 
in the development of sequence uploads. A 
mission level system engineer should have 
the authority and responsibility to perform 
such tradeoffs at a high level. 
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System Commonality 

Build systems that achieve simplicity 
through the use of common architectures. 
Cost savings due to system commonality 
may not be apparent at the mission opera- 
tions level, but are observable at the pro- 
gram level. Many Integration and Test 
(I&T) functions are duplicated in the Mis- 
sion Operations System and vice versa. 
Why should these capabilities be developed 
twice? Using a common system design for 
Mission Operations (MO) and I&T saves 
money not only in design and development 
of the ground system, but in sparing, training 
of personnel, and staffing during test, 
launch, and mission ops. 

Operations 

The division of operations costs between 
pre- and post-launch is mission dependent. 
Pre-launch development of operations teams 
and processes, personnel training, and sys- 
tem testing can be significant cost items. If 
the mission is short, or if it can be staffed at 
a very low level, pre-launch costs can be a 
significant portion of overall operations 
costs to the program. If the mission is long, 
complex, or both, post-launch costs tend to 
be the driver of overall costs. In the sections 
that follow, we shall show how intelligent 
application of pre-launch funding can signif- 
icantly reduce post-launch costs. 

Low Staffing Levels 

Minimize the number of personnel 
needed to operate the spacecraft during 
post-launch operations. The major post- 
launch cost item for most missions is per- 
sonnel. In most programs, the key to lower- 
ing operations costs is to reduce the number 
of people required to operate the spacecraft. 

Personnel reductions can be achieved 
merely by paying attention to the type and 
capabilities of personnel hired and the 
changes in skills needed during different 
phases of the mission. As teams become 
smaller, the competence and breadth of 
individual members becomes more impor- 
tant. Small teams can not afford to have 
members with specialized or limited skills; 
every team member must contribute signifi- 
cantly to the overall productivity of the team 
for operations to be cost efficient. 


It is important to note that the skills 
required during design and development of 
the MOS are not the same as those required 
during post-launch operations. Personnel 
should be added as their skills are required 
and removed when their skills are no longer 
applicable to the needs of the program. This 
may conflict with the policies of some 
organizations, but is essential to controlling 
operations costs. Large institutions fre- 
quently utilize matrix management tech- 
niques that allow the program to draw from 
a broad mix of skilled personnel, paying 
only for the time charged to the program. 
Matrix techniques can be advantageous in 
the implementation of these practices. 

Spacecraft Autonomy 

Build spacecraft systems that require 
minimal operations support. Perhaps the 
most obvious way to reduce operations cost 
is to build a spacecraft that does not require 
operations! The more autonomy built into a 
spacecraft, the less the MOS needs to do. 
The prevailing view is frequently the inverse 
- the more the ground does, the less the 
spacecraft needs to do. Mission system 
engineering of the spacecraft and MOS 
offers the capability to partition require- 
ments between the ground and flight sys- 
tems. If the optimization goal is to minimize 
overall program costs, operations costs will 
generally be lower. Even if cost is not an 
optimization parameter, the consideration of 
mission operations issues in the design of 
the spacecraft will generally result in cost 
savings (due to operability enhancements). 
Frequently, the spacecraft design team has 
options that have little impact on the space- 
craft but significant advantage to mission 
operations. 

Spacecraft autonomy features which 
simplify operations include: telemetry moni- 
toring and alarming; processor memory 
management; anomaly detection, correction, 
and/or reporting; automated data handling; 
and multi-level autonomous safe modes. 
Each of these features are discussed below. 

Autonomous telemetry monitoring and 
alarming reduces the work load on ground 
personnel, especially if the MOS is designed 
to communicate spacecraft generated alarms 
to operations personnel immediately. This 
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reduction in the need for ground system 
monitoring reduces the number of personnel 
and the frequency of contacts required. Dur- 
ing missions with long cruise phases and 
infrequent contacts, onboard alarming, cou- 
pled with storing alarm status in memory, 
can enable operations personnel to instanta- 
neously assess the state of spacecraft health 
since the last contact. This reduces the con- 
tact time required, the operations load, and 
thus, the total cost to the program. 

Automation of memory management 
allows the MOS to use lower fidelity models 
of onboard processors, thereby reducing 
development costs. Additionally, fewer 
commands are required for processor mem- 
ory management, reducing the costs of test- 
ing those commands as well as simplifying 
operations. 

Autonomous anomaly detection, correc- 
tion, and reporting is similar to onboard 
telemetry monitoring and alarming with 
respect to operations. The potential reduc- 
tion in operations workload and the increase 
in intervals between contacts results in a 
reduction in operations personnel. 

Autonomous data handling, in which the 
spacecraft processes, stores, and retrieves 
data by instrument or subsystem without 
detailed operator intervention, allows the 
operations team to use contact time more 
efficiently and send fewer commands, 
reducing the workload and cost of oper- 
ations. 

Multi-level safe modes allow the space- 
craft to assume intermediate modes of 
operation between fully operational and 
"cocoon'' mode (minimal activity, awaiting 
ground command). For example, a failure in 
the data handling system may cause the 
spacecraft to shut down the data handling 
system, point the antenna at Earth (assuming 
guidance, navigation and control functions 
are unaffected), and await instructions. 
Allowing the good subsystems to remain 
operational means that the anomaly will be 
addressed more quickly than would other- 
wise be the case. This allows for longer 
intervals between contacts, which reduces 
operations loads and costs. This also 
reduces the time spent and the assets utilized 
in recovering from a failure. 


Ground System Automation 

Build ground systems that minimize per- 
sonnel requirements. The use of automation 
in the ground system can significantly 
reduce requirements on operations person- 
nel. Most apparent is the application of 
automated telemetry display and command 
generation capabilities. The use of high 
level command languages reduces opera- 
tions personnel requirements, as do inte- 
grated databases, graphical user interfaces, 
and automatic report generation and trans- 
mission capabilities. 

The next logical step in ground system 
automation is ground systems that 
autonomously receive, process, interpret, 
and respond to spacecraft telemetry. While 
totally automated operations are not yet fea- 
sible for scientific missions, many functions 
can be automated. Automated monitoring of 
telemetry can not only alert an operator to an 
out-of-bounds condition, it can spawn a pro- 
cess to advise the operator what to do (i.e., 
retrieve a contingency plan from a database), 
or even take action itself (depending on the 
nature and severity of the anomaly). Space- 
craft data trending and analysis can be 
highly automated, generating formatted 
reports and delivering them electronically to 
the correct parties at the appropriate times 
(e.g., at shift changes or on Monday morn- 
ings). Clearly, all of these capabilities can 
be used to reduce the personnel otherwise 
needed to perform these tasks. 

Advanced Technology 

Utilize advanced technologies, where 
applicable, to enhance productivity in 
operations. The application of advanced 
technology throughout Discovery class mis- 
sions has been mandated by NASA (the 
NEAR mission design predates this man- 
date, and NEAR is specifically exempted 
from this requirement). Advanced technol- 
ogy can reduce operations costs by enhanc- 
ing productivity, i.e., allowing fewer people 
to accomplish more work with fewer 
resources expended. Two ways in which 
advanced technology can be used to enhance 
productivity are: 1) advanced technology 
can enable the use of higher level interfaces 
to gain insight into data and processes, and; 
2) advanced technology can be used to assist 
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in making decisions. The application of 
advanced graphical techniques to gain 
insight into complex data sets is called 
visualization ; and the use of software to 
assist in decision making processes falls in 
the category of expert systems. 

Visualization 

Everyone has seen global maps with 
projected spacecraft ground traces, coverage 
circles of ground receiving sites, and per- 
haps time ticks indicating when a spacecraft 
will or did pass over a particular spot - 
these types of displays were a staple of the 
highly publicized manned space missions of 
the 1960’s. This type of display is a prime 
example of the use of visualization to 
provide insight into a complex data set - in 
this case, the orbital ephemeris of the 
spacecraft, the locations and views of each 
of the ground network's tracking stations, 
and the time the spacecraft will be available 
for contact at each of the ground stations. 

Humans excel at the assimilation of 
visual information. The recent trend in 
returning to traditional watches and clocks 
from the digital variety is evidence of this 
phenomenon. People easily interpret the 
time of day from the angles of clock hands, 
whereas a digital clock requires assimilation 
and interpretation to understand. Computer 
graphics are a powerful tool for taking 
advantage of this characteristic of the human 
brain to reduce operations costs. The trend 
in operations systems is away from 
alphanumeric screens with numbers and 
cryptic mnemonics towards graphical dis- 
plays, including analog dials, graphs, and 
trees of color coded boxes representing 
spacecraft systems and subsystems, etc. 
Aircraft cockpits with modem CRT and flat- 
panel displays utilize representations of 
analog dials and "tape" gauges for the same 
reasons operations systems do; these dis- 
plays rapidly and intuitively present more 
information to the user more quickly than 
alphanumeric displays, thus allowing fewer 
people to monitor a complex system more 
efficiently and completely - and with fewer 
errors. Fewer people mean lower costs, and 
fewer errors mean greater spacecraft safety. 


Expert Systems 

More advanced than visualization 
(already in use in operations centers, albeit 
sparingly) is the use of expert systems to 
assist in decision making processes. Rule- 
based expert systems are currently in use in 
some operations systems to assist in teleme- 
try monitoring and display functions. Rule- 
based systems may also be used in the near 
future to help diagnose spacecraft anoma- 
lies, again, based on interpreting spacecraft 
telemetry. In artificial intelligence circles, 
however, rule-based systems have fallen out 
of favor because of their inherent lack of 
robustness; these systems can only apply 
pre-programmed rules to a known data set, 
and can be very difficult to adapt rapidly to 
changing conditions. For complex systems, 
the rule sets can get very large and difficult 
to manage. Finally, rule-based systems 
require ail rules to be programmed before 
the system is very useful. 

Model-based systems are being investi- 
gated for spacecraft operations because they 
address these problems. Model-based rea- 
soning (MBR) methods use models of sys- 
tems and subsystems to make estimates of 
systems states. MBR allows incremental 
growth in capability as models are added, 
refined, or updated, and can provide answers 
that are both qualitative and quantitative. 
MBR can be used to diagnose problems 
based on spacecraft telemetry, but the mod- 
els can also be used to support analysis in 
the sequence generation process. 

Model-Based Reasoning appears likely 
to reduce MOS costs in two ways. First, it 
may allow the development of a single set of 
spacecraft models to perform planning, anal- 
ysis, and assessment functions, thereby 
reducing system development costs over 
traditional MOS designs. Second, it may 
allow fewer analysts to generate very com- 
plex spacecraft sequences with greater con- 
fidence, thereby reducing personnel require- 
ments while enhancing mission capability. 
MBR may be a suitable alternative to the 
building of costly hardware-based spacecraft 
simulators traditionally used for command 
sequence vetting. 
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Figure 1 is a high level diagram of the 
NEAR Ground System (NGS). There are 
six major ground facilities: the Mission 
Operations Center (MOC); the Ground Sup- 
port System (GSS); the Mission Design 
Center (MDC); the Science Data Center 
(SDC); the Mission Navigation Center; and 
the Deep Space Network (DSN), which is 
linked via NASA Communications 
(NASCOM) circuits at Goddard Space 
Flight Center (GSFC). 

Mission operations will be conducted 
from APL. Therefore, the MOC and MDC 
are located at APL. The principal equip- 
ment in the MOC is a suite of interface 
equipment and high-end workstations, 
including software, known as the Mission 
Operations Ground Segment (MOGS). 

The GSS includes a parallel construction 
called the Integration and Test Operations 
Ground Segment (ITOGS) as well as the 
Ground Support Equipment (GSE). The 
GSS is used to perform integration and test 
of the spacecraft at APL, environmental 


testing at GSFC, and prelaunch testing at the 
launch site. The ITOGS and MOGS are 
identical; by virtue of the interconnecting 
data network called NEARnet, each has con- 
trolled access to the spacecraft. 

Science data received by the MOC is 
processed and passed on to the SDC, which 
further processes the data for dissemination 
to the science community. The Mission 
Navigation Center, located at the Jet Propul- 
sion Laboratory (JPL), provides navigation 
data and products to the MOC, the SDC, 
and the MDC. 

Existing Infrastructure 

The NEAR Ground System maximizes 
the use of existing infrastructure, including 
the DSN and NASCOM. The DSN is used 
for all TT&C for NEAR. Operated by JPL, 
the DSN is a ground network primarily used 
for interplanetary missions, with ground sta- 
tion complexes in Barstow, California, 
Madrid, Spain, and Canberra, Australia. 

Access to the DSN is provided via 
NASCOM. NASCOM will be used for vir- 
tually all NEAR communications. This 
includes extensions of the NEARnet to the 
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ITOGS as it moves with the spacecraft to 
GSFC and to the Kennedy Space Center 
(KSC) and Cape Canaveral Air Force Sta- 
tion (CCAFS). The cost effectiveness of 
using NASCOM for NEAR is multiplied 
because the arrangements for its use are 
provided by the DSN as a service. 

A third major use of existing infrastruc- 
ture is internal to APL. As discussed, the 
workstations, GSE, and peripherals of the 
MOGS and ITOGS are tied together as one 
large system via the NEARnet. Within 
APL, NEARnet uses an existing ethernet 
communications system called the APL 
Network Information System (APLNIS). 
APLNIS is ubiquitous throughout APL and 
supports multiple interface configurations. 
APLNIS supports TCP/IP protocols and has 
an existing connection to Internet, which 
provides off-campus access to the SDC. 
Connections of the ITOGS and MOGS to 
the APLNIS will utilize a router to provide 
protection against unauthorized access to 
spacecraft control and telemetry. 

It should be noted that the NEAR space- 
craft conforms to the standards of the Con- 
sultative Committee on Space Data Systems 
(CCSDS), and will be the first spacecraft to 
use CCSDS for uplinking. In using this 
system, NEAR is effectively making use of 
another set of existing infrastructure that 
results in reduced costs within the NGS. 

Commercial-0 ff-T he-S hel f Systems 

An important aspect of the NGS imple- 
mentation approach is the use of COTS mis- 
sion operations systems. Although this 
industry is still young, a number of available 
systems offer capabilities in one or more 
aspects of spacecraft telemetry processing, 
performance assessment, and command and 
control. The core of the NGS is COTS. 
This core provides telemetry monitoring, 
alarming, and archiving, as well as 
spacecraft command and GSE control. Two 
systems are being procured for the MOGS 
and ITOGS; when augmented with 
additional workstations and custom software 
developed by APL, they will constitute the 
ITOGS and MOGS. 

The core system includes a VME-based 
front-end, a workstation, and peripherals. 


The front-end provides the telemetry and 
command interfaces to the spacecraft (or 
more correctly, the spacecraft GSEs and/or 
the DSN via NASCOM) as well as realtime 
decoding, error correction, and data handling 
required to provide data for display on 
operator workstations. Workstation process- 
ing includes calibration, engineering unit 
conversions, display, alarming, and com- 
mand script generation. Workstations may 
analyze realtime or archived data, or a 
combination. A large number of worksta- 
tions can be supported on the NEARnet, and 
as described previously, these can be located 
anywhere. 

Like many other current COTS systems, 
the NEAR MOC and GSS use networking 
and distributed processing. In each area, the 
workstations, peripherals, and command and 
telemetry interfaces are merely logical 
groupings of equipment on the NEARnet, 
with equal access to all data whether it 
enters the system via the MOC or the GSS. 
Each workstation has equal access to the 
"front end" of either area. The look and feel 
of the system remains the same in all 
locations; the parallel nature of the 
networked system provides a mutual backup 
capability. 

This networked architecture permits the 
system to take advantage of distributed pro- 
cessing. The NEAR MOS has no large cen- 
tral computer with the resultant interference 
and speed problems as different worksta- 
tions access and run processes on the central 
facility. These workstations simultaneously 
and independently run different processes on 
the same or different realtime or archived 
data. This permits a single database (e.g., 
telemetry and command dictionaries) to be 
accessed from any workstation, preventing 
the problems of maintaining multiple dictio- 
naries. Incremental growth in the ground 
system can be easily accommodated without 
disrupting existing (operating) components. 

The NEARnet extends beyond the 
MOGS and ITOGS, providing controlled 
(authorized) access to selected data on the 
NEARnet by other workstations or PCs. 
One recipient of data is the Science Data 
Center (which also has workstations and 
peripherals connected to the NEARnet). 
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The SDC is given essentially raw science 
data at the CCSDS Transfer Frame and 
Packet level and provides various levels of 
processing to generate products for the sci- 
ence community, which accesses these 
products via the NEARnet. Off-campus sci- 
ence teams may obtain access via the Inter- 
net. Two other Centers have access to the 
NEARnet Science Data Center. These are 
the Mission Design Center and the Mission 
Navigation Center. 

One additional aspect of the ITOGS and 
MOGS worth noting is the use of an open 
operating system. All of the commonly rec- 
ognized advantages of this approach are 
realized for NEAR. For example, access to 
commercial software is maximized; in-house 
software can be developed on non-NEARnet 
workstations or PCs with minimum prob- 
lems in transporting these to MOS worksta- 
tions. Further, the NEARnet configuration 
is much more supportable and expandable 
over the life of the mission. 

Common architecture for I&T and MO 

It is important to note that the MOGS 
and ITOGS are identical in configuration, 
software, hardware, and command and 
telemetry capability. This is significant in at 
least two aspects. First is the reduced devel- 
opment and maintenance costs resulting 
from identical workstations, front-end 
equipment, and peripherals. Because a 
single system design and architecture is 
used, overall complexity and design effort is 
reduced, as is the number and cost of pro- 
cured components. Additionally, spares and 
maintenance costs are minimized. 

The second significant aspect of using 
identical systems for I&T and MO is that the 
spacecraft will be flown as it was tested. 
The look and feel of the two segments is the 
same to the user. Since both sets of front- 
end equipment are also identical, (each sup- 
porting the three modes of interface with the 
spacecraft: RF GSE, umbilical GSE, and via 
NASCOM and the DSN), and since either 
can be accessed from a workstation in either 
the MOGS or ITOGS, the only distinction 
between the two is established by access 
authorization. While I&T activities will be 
principally controlled from the ITOGS due 
to its proximity to the spacecraft and GSE, 


considerable capability exists, and will be 
utilized, to exercise the spacecraft from the 
MOC during the I&T phase. When this 
commonality of hardware and software is 
considered in light of the current plan to 
have a number of mission operations per- 
sonnel involved in integration and test, the 
transition from I&T to MO should be as 
seamless as is achievable. This blending of 
traditionally separate and distinct functions 
significantly reduces the total cost and 
development time for the ground support 
elements of the NEAR mission while 
improving the quality and reliability of the 
overall product. 

SUMMARY 

This paper began with a discussion of 
low cost mission operations, including a 
number of specific recommendations for 
controlling costs. These are summarized 
below: 1) Always take advantage of existing 
infrastructure where cost efficient; 2) Use 
Commercial Off-The-Shelf hardware and 
software systems where applicable and cost 
effective; 3) Use modern concurrent engi- 
neering techniques; 4) Design the spacecraft 
and Mission Operations System for oper- 
ability; 5) Build systems that achieve sim- 
plicity through the use of common architec- 
tures; 6) Minimize the number of personnel 
needed to operate the spacecraft during post- 
launch operations by building spacecraft and 
ground systems that minimize personnel 
requirements, and; 7) Utilize advanced tech- 
nologies, where applicable, to enhance pro- 
ductivity in operations. While these simple 
statements may seem obvious, they are fre- 
quently forgotten or overlooked as heritage 
often dictates the design and implementation 
of the MOS. 

The second part of the paper included a 
description of the NEAR MOS and ground 
system with an emphasis on those elements 
of the system design that contribute to low 
cost operations. In the case of NEAR, we 
were able to apply almost all of the practices 
discussed in this paper. It is our hope that 
NEAR Mission Operations will introduce a 
new way of doing business for Discovery, 
and that this will lead others to identify even 
better approaches to controlling costs in 
today's cost-constrained environment. 
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